前言：片段數量對了，合併出來的結果卻怪怪的

前幾天講的斷點續傳、局部重試，解決的都是「片段有沒有成功下載」；但即使所有片段都成功下載、數量也對，合併出來的結果還是可能有問題——這個系列素材專案裡真實遇過的一次案例，是合併出來的內容裡，有一小段畫面解析度跟其他片段明顯不一致。

今日目標

• 認識「片段數量對」不等於「片段都屬於同一份內容」
• 看懂為什麼會有規格不一致的片段混進清單裡
• 看一組「只信任片段數量 vs 逐一驗證片段規格」的對照

為什麼會有規格不一致的片段

HLS 是業界廣泛使用的串流協定，很多提供串流服務的平台（不管合法與否）會在內容中間插入廣告片段——這是一個有明確標準支援的機制（SCTE-35 是業界常見的廣告插入標記規範），插入的廣告片段通常跟主要內容的解析度、編碼參數不同。如果下載流程只把 M3U8 清單裡列出的片段一視同仁地全部下載、全部合併，插入的廣告片段就會被一起接進最終輸出裡。

❌ vs ✅：只看數量 vs 逐一驗證規格

❌ 反例：片段數量對了就直接合併

def merge(files: list[str], output: str):
    with open(output, 'wb') as out:
        for file in files:
            with open(file, 'rb') as f:
                out.write(f.read())  # 來者不拒，全部接起來

✅ 正例：以第一個片段的媒體資訊為基準，逐一驗證

def merge(files: list[str], output: str):
    base_info = get_media_info(files[0])

    with open(output, 'wb') as out:
        for file in files:
            info = get_media_info(file)
            if info.get('width') != base_info.get('width') or \
               info.get('height') != base_info.get('height'):
                continue  # 規格跟基準不符，視為不該存在的片段，跳過

            with open(file, 'rb') as f:
                out.write(f.read())

用第一個片段的解析度當基準，逐一比對每個片段是否吻合，不吻合的片段直接排除在合併之外。

這個驗證機制建立在一個前提上

用「第一個片段」當基準隱含一個假設：第一個片段一定屬於主要內容，不會剛好就是被插入的片段。如果這個假設不成立（例如插入內容剛好出現在最前面），基準本身就是錯的，後面的驗證會全部反過來。實務上更穩健的做法，是取多個片段的規格做多數決，而不是只信任單一個樣本——這是這個驗證機制目前還沒處理到的侷限。

今日思考題

你驗證過「一批資料裡是不是混進了不該有的項目」嗎？你的驗證基準是怎麼選出來的？有沒有想過，如果基準本身剛好就是異常值，驗證邏輯會怎麼壞掉？

今日重點回顧

• 片段數量正確，不代表每個片段都真的屬於同一份內容
• 用媒體資訊（解析度等）逐一比對，可以濾掉規格不一致的片段
• 驗證基準的選擇本身有前提假設，基準選錯，驗證邏輯也會跟著錯

明日預告

明天是第二部回顧：把 HLS 協定拆解成一連串可以逐步驗證的小問題,這個系列到目前為止的方法論收斂。